CacheCloud 1.2更新列表

本文用几星代表更新内容的重要性，星数越多，功能越重要。

升级1.2方法请参考：CacheCloud 1.1升级到1.2

[fix]

• 1、修复导入的应用，不能立即使用应用慢查询功能（2星）
• 2、修复Redis Sentinel节点包含添加slave功能（2星）
• 3、修复非Redis Cluster水平扩容功能（2星）
• 4、修复系统配置的值不能为空（3星）
• 5、修复系统配置修改对cachecloud多机器部署无效（3星）

[new]

• 1、数据迁移工具（5星）
• 2、Redis配置模板（5星）
• 3、Session和Cookie两种用户状态（3星）
• 4、支持修改单个节点的配置（4星）
• 5、应用客户端连接数报警（3星）
• 6、机器可以设置根路径（4星）
• 7、邮件和短信报警支持http接口（4星）
• 8、支持LDAP登录（4星）
• 9、添加Redis碎片率收集和展示（4星）
• 10、添加AOF阻塞收集和展示（4星）
• 11、部署应用前检查配置是否正确（5星）
• 12、删除机器验证（3星）
• 13、增加appkey和RestApi（4星）
• 14、定时删除数据的问题（3星）
• 15、客户端连接数图表 (3星)
• 16、应用机器实例拓扑结构 (4星)
• 17、Cachecloud日报功能 (4星)
• 18、CacheCloud版本提示 (3星)
• 19、quartz相关优化 (4星)

[fix]:

1. 修复导入的应用，不能立即使用应用慢查询功能

描述：1.2版本之前，如果是导入的应用，必须重启cachecloud才可以使用应用慢查询功能，1.2版本对这个问题进行了修复。

导入的应用是指已存在Redis接入CacheCloud

2.修复Redis Sentinel节点包含添加slave功能

描述: 1.2版本之前，应用运维界面(Redis Sentinel类型)，Sentinel节点有添加slave按钮，实际是无用的。1.2版本对这个问题进行了修复。

3.修复非Redis Cluster水平扩容功能

描述: 1.2版本之前，Redis Sentinel和Standalone类型应用在扩容时有水平扩容按钮，实际是无用的。1.2版本对这个问题进行了修复。

4. 修复系统配置的值不能为空

描述: 1.2版本之前, 系统配置的值不能为空。1.2版本对这个问题进行了修复。

5. 修复系统配置修改对cachecloud多机器部署无效

描述：系统配置修改后只对当前执行的机器有效，如果是多机部署cachecloud其他机器接收不到。1.2版本对这个问题进行了修复。

ps:为了减少技术栈，没有使用zookeeper，mq等形式，而是采用cachecloud每隔30秒更新一次配置的形式，所以实际使用中，多机部署可能配置生效有30秒的延时。

[new]:

1.迁移数据工具：

1.2版本，提供了数据迁移工具，可以完成如下功能。

• 可以在rdb、Redis Standalone、Redis Sentinel、Redis Cluster、rdb、aof(目前只支持作为source)之间进行数据迁移(也可以直接是CacheCloud的应用，也就是appId)
• 数据迁移可以尽可能保证一致性
• 迁移过程可视化完成流程的控制

感谢唯品会开源的redis-migrate-tool,cachecloud就是基于这个工具实现的。

下面是示例：
迁移工具页面：

迁移列表：

迁移状态日志

迁移状态查询

---

详细的使用说明,在这里

---

2. Redis使用模板进行配置：

1.2版本之前，CacheCloud使用的Redis的配置是硬编码在代码中的，可以参考Cachecloud中Redis的相关配置，具体是这三个类:

RedisConfigEnum
RedisClusterConfigEnum
RedisSentinelConfigEnum

虽然配置上我们做了一些优化，但是每个公司对于Redis的配置可能不尽相同，但是改源码对于许多对于java不太熟悉的朋友来说是比较麻烦的，于是考虑到两个点，1.2版本我们做了一个配置模板的功能，可以实现对配置的增删改查：

总览：

添加配置：

配置预览：

---

详细的使用说明,在这里

---

3. 用户可以选择cookie和session两种形式保存用户状态

1.2版本之前，默认使用session保护用户的状态。但是如果cachecloud使用了多机部署，那么session状态可能会在几台机器来回漂移，这种形式很不友好，有关session共享的问题，有很多的解决方法，比如集中管理session，但是最简单的方法就是用cookie，为此1.2版本提供了cookie的功能，设置方法也很简单，在系统配置中进行修改。(默认值是session)

session共享问题:

如果想使用session:

如果想使用cookie:

使用cookie需要有自己的域名，无论测试环境还是生产环境都需要用域名进行访问（例如本地测试需要绑定域名host）。

注意：该配置必须重启cachecloud才可以生效。如果想第一次设置不重启，可以修改数据库。

session:
update system_config set config_value=1 where config_key='cachecloud.user.login.type';

cookie:
update system_config set config_value=2 where config_key='cachecloud.user.login.type';
update system_config set config_value='你的域名' where config_key='cachecloud.cookie.domain';

4. 支持修改单个节点的配置

1.2版本之前，修改配置实际修改了应用下所有的配置，但实际上有时候我们需要对个别实例的配置做一些特殊的”优化”，所以cachecloud在1.2版本开始支持单个实例配置修改。

修改应用下所有的实例的某个配置：

修改单个实例的配置：（但是依然建议配置统一化，至少主从要一致化）

5. 机器可以设置根路径：现在必须是opt目录

1.2版本之前，redis必须安装在/opt目录下，鉴于各个公司对软件安装目录的差异，在1.2版本可以设置redis的根目录，但是根目录下的其他目录必须还安装之前的约定，例如

${base_dir}代表根目录
数据目录 ${base_dir}/data
配置目录 ${base_dir}/conf
日志目录 ${base_dir}/logs
redis安装目录 ${base_dir}/redis

如果改变了根目录，需要修改cachecloud-init.sh脚本，所有/opt都换成你的${base_dir}，具体配置方法，进入系统配置

注意1：该配置必须重启cachecloud才可以生效。如果想第一次设置不重启，可以修改数据库。

update system_config set config_value='你的等目录，例如/data,/xxx' where config_key='cachecloud.base.dir';

注意2：上述配置还是整体配置，没有做到一台机器一种目录，所以这个一定要提前规划化好。

6. 应用客户端连接数报警:

1.2版本添加了应用客户端连接数的报警，用户可以通过两个方法进行设置
(1). 申请应用

(2). 修改配置
应用详情页面，点击应用报警配置

当超过预设阀值时候，会收到如下报警(前提是短信和邮件接口已经添加，下一个小节)：

分片(10.10.xx.xx:6414,应用(10305))客户端连接数报警-预设2000-现已达到2511-请及时关注

7. 邮件和短信报警支持http接口：不限制java语言，后续文档会给出规范

1.2版本之前，邮件和短信报警是需要将自己公司的报警代码逻辑写到cachecloud中的(详见wiki)，鉴于使用cachecloud的有许多是运维人员，有可能对java不是很熟悉，我们在1.2版本提供了http接口规范，只要按照规范开发http接口，任何语言都可以。

(1) 邮件：

参数	含义	是否必须
title	邮件标题	是
content	邮件内容	是
receiver	收件人列表	是
cc	抄送人列表	否

例如我们用python语言按照上面的参数开发了一个http接口

www.xxx.com/emailAlert?title=xx&content=xx&receiver=x&cc=x

(2) 短信：

参数	含义	是否必须
msg	短信内容	是
phone	手机号列表	是

例如我们用python语言按照上面的参数开发了一个http接口

www.xxx.com/shortMsgAlert?msg=xx&phone=xx

(3) 修改系统配置：

确认无误后，我们需要把它添加到系统配置修改中即可：

8. 支持LDAP登录

1.2版本之前，用户登录密码验证是需要将自己公司的登录代码逻辑写到cachecloud中的(详见wiki)，鉴于使用cachecloud的有许多是运维人员，有可能对java不是很熟悉，我们在1.2版本提供了LDAP接口，这样只需要将LDAP接口进行配置，就可以实现公司内部的登陆验证了。
具体修改方法，在系统配置中，修改LDAP接口:

9.添加Redis碎片率收集和展示

Redis的内存碎片率是一个很重要的数据，较高的内存碎片率可能会造成系统内存的浪费，所以有必要定期收集和展示。

具体显示在两个地方:

(1) 应用拓扑界面

(2) 应用运维界面

显示规则

如果Redis内存使用了很少，有可能造成碎片率过高的情况，我们忽视了这种情况，只有在Redis单个节点使用内存超过100M时候，才会重点突出碎片率高的节点，例如：

• 碎片率小于3，正常(绿色)
• 碎片率在3到5之间，警告(橘黄色)
• 碎片率大于5, 危险(红色)

10.添加AOF阻塞收集和展示

如果Redis开启了AOF，那么AOF运行是否正常直接决定着Redis服务是否正常，这里只是抛砖引玉，我们已经计划在1.3版本加入AOF和RDB控制中心的功能。

11.部署应用前检查配置是否正确

为了防止人为输入出错，在应用部署时添加了校验机制，形如下图，必须在格式检查成功后才可以部署应用。

检测规则

• 输入框下面的规则.
• 检查机器是否在机器列表中.
• 如果是Redis Sentinel应用必须有3个以上的Sentinel节点(强制)

12. 删除机器前要验证机器上是否有用cachecloud开启的Redis节点

删除机器前，确认该机器上是否有正在运行的Redis节点(必须是cachecloud开启的或者导入的，自己在机器手工安装的Redis除外)

13. 增加appkey和RestApi

1.2之前的版本，客户端直接可以通过带appId参数的Restful API就可以访问到应用的实例信息。
众所周知，appId是递增的，这样使用者存在误操作和恶意操作的可能性(只需要改一下appId)，存在一定的安全隐患，因此需要一个秘钥在cachecloud服务端进行验证，因此新版本中添加appKey秘钥，这个秘钥在应用申请成功后就会自动生成，并且展示到了应用详情页面。

同时添加了新的RestApi(老版本的API依然可以使用)
原api,详情

http://ip:port/cache/client/redis/${appType}/{appId}.json?clientVersion=xx

appType=cluster|sentinel|standalone

新api，添加了appkey参数(必须的)，路径上简单的添加了/safe路径(为了方便)

http://ip:port/cache/client/redis/${appType}/safe/{appId}.json?clientVersion=xxxx&&appKey=xxxx

appType=cluster|sentinel|standalone
appKey是秘钥

14. 定时删除数据的问题

cachecloud在搜狐视频现在有接近1000个节点，不算特别大，但是例如每分钟收集各个节点数据以及客户端的数据，日积月累数据量会比较大，而mysql在存储大量数据时候会比较麻烦，所以cachecloud会定期清理各种数据(详见CleanUpStatisticsJob类)，但是可能实际上各个公司的节点数不一样，有些公司可能不需要定期清理数据，因此1.2版本提供了一个开关来决定是否定期清理统计数据，在系统配置进行修改就可以了。

15. 客户端连接数图表

应用首页最下方添加客户端连接数图表：

16. 应用机器实例拓扑结构

应用页面添加新标签应用拓扑，用于观察应用分配机器是否合理以及机器分配实例数观察等。

17. Cachecloud日报功能

CacheCloud每天10点会给各个应用的使用者发送一份日报邮件，是关于前一天CacheCloud的一些使用情况，如下图所示:

此功能需要第7小节邮件和短信报警支持http接口功能

18. CacheCloud版本提示

通过点击下拉菜单可以看到当前CacheCloud的版本

19. quartz相关优化

优化了quartz线程池，防止大量慢任务阻塞掉quartz线程池。